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(54) Packet ordering method and apparatus in a mobile communication network 



(57) The present invention, in particular, refers to Is 
a data packet ordering method in a mobile communica- 
tion network employing hierarchical routing with data 
packet forwarding comprising the step of providing at 
least one data message encompassing a predefined se- 
quence of data packets, forwarding at least one of said 
data packets of the sequence via a first network element 
over a first transmission path to a user equipment, 
whereby a part of the data packets are temporarily buff- 
ered in the first network element during transmission, 
establishing a second transmission path, while forward- 



ing the data packet sequence, such that the remaining 
data packets of the sequence not yet transmitted over 
the first path are forwarded via a second network ele- 
ment, forwarding of the data packets buffered in the first 
network element to the second network element for pro- 
viding all data packets comprised by the data packet se- 
quence to the user equipment, receiving and ordering 
of the data packets within said second network element 
according to the packet data priority given by the data 
packet sequence, forwarding the ordered data packets 
to the user equipment. 



Fig. 1 
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Description 

BACKGROUND OF THE iNVENTION. 

1. FIELD OF THE INVENTION. 

[0001] The Invention relates to a data, and to an ap- 
paratus or a mobile communication system, and a com- 
puter program for carrying out the method. 

2. DESCRIPTION OF RELATED ART. 

[0002] In wireless data packet switched networks, 
and especially in code divisional multiple access sys- 
tems (CDMA) like the universal mobile telecommunica- 
tion system (UMTS) or the time division multiple access 
system (TDMA) like general packet radio systems 
(GPRS) hierarchical routing Is used for mobility support. 
[0003] In case of packet switch exchange, in the con- 
nectionless mode of a telecommunication systems, the 
packet data are queued and generally buffered, respec- 
tively, in a distributed manner at the respective route net- 
work subsystem (RNS) and in the backbone network, e. 
g. in the serving radio network subsystem (SGSN). The 
distribution of the data is out of control and defined by 
flow control mechanisms, which are subject to individual 
parameter settings. 

[0004] Figure 1 shows an example of an UMTS ter- 
restrial network in the packet switched domain with in- 
ter-RNS/ intra-SGSN hand-off or hand-over. One SG- 
SN, which is somehow connected to other SGSN or to 
a other gateway GPRS supporting node (GGSN), is 
connected to two RNS#1 and #2 and to the dedicated 
BTS (base transceiver station or nodeB) respectively. In 
case of GPRS RNS has to be replaced by a base-station 
subsystem (BSS) with similar functionality. The mobile 
station (MS) is assumed currently connected to RNS#1 . 
This connection is denoted by 1, When the MS moves 
from RNS#1 towards RNS#2 an inter-RNS/lntra-SGSN 
handover occurs, where in the final stage the MS is con- 
nected to RNS#2. This connection is denoted by 2. 
[0005] In the case depicted in Fig. 1, it is assumed 
that flow control has data buffered in both element lev- 
els, i.e. in RNS#1 as well as in SGSN. Flow control pa- 
rameters dictate the distribution of the packet data be- 
tween network elements. 

[0006] During hand-over, the mobility support at node 
SGSN results in a new packet path to RNS#2. Given 
that packet forwarding Is activated, i.e. RNS#1 forwards 
the buffered packets to the new destination, this will lead 
to two different packet paths to the target RNS#2. Drop- 
ping the buffered packets at RNS#1 is not an option for 
reliability performance. Therefore, packets may become 
reordered at the new target RNS#2. which contains the 
buffer of the bottleneck air-link. Then, without reorder- 
ing, the MS receives out of sequence packets after 
hand-over. 

[0007] In this case the transmission control protocol 



(TCP) receiver in the MS will "slowly" receive some 
packets, and request erroneously TCP retransmissions 
resulting in spurious retransmission, which erodes the 
transmission control protocol (TCP) throughput and 

5 wastes system resources. Due to the higher network de- 
lays this becomes more critical for inter-RNS/inter-SG- 
SN hand-overs where more than one SGSN is involved. 
[0008] In UMTS this problem could be partly solved 
using the loss-less serving radio network subsystem 

10 (SRNS) relocation procedure as specified in the current 
third generation partnership project {3GPP) UMTS 
standards. Because this procedure works on the radio 
link control (RLC) layer tight requirements on timing, 
buffering, etc. must be fulfilled to fully avoid packet re- 

15 ordering. However to significantly relax these require- 
ments a method would be necessary that handles pack- 
et reordering on a higher layer than RLC. In GPRS there 
is no such procedure defined in the standards. Here, a 
method is necessary to handle the reordering effects in 

20 general. 

[0009] In response to the concerns discussed above 
it is the object of the present invention to provide espe- 
cially a method and an apparatus which allows reorder- 
ing on a higher layer than radio link control layer in a 
25 wireless data packet switched network. 

SUMMARY OF THE INVENTION. 

[0010] The inventive solution is obtained by a data 
30 packet ordering method according to claim 1 , by an ap- 
paratus and/or a mobile communication system accord- 
ing to claim 9, and by a computer program defined in 
claim 10 

[0011] Preferred and/or advantageous embodiments 
35 or refinements are subject of the respective dependent 
claims. 

[0012] The present invention, in particular, refers to a 
data packet ordering method in a mobile communication 
network employing hierarchical routing with data packet 

40 forwarding comprising the step of providing at least one 
data message encompassing a predefined sequence of 
data packets, forwarding at least one of said data pack- 
ets of the sequence via a first network element over a 
first transmission path to a user equipment, whereby a 

<5 part of the data packets are temporarily buffered In the 
first network element during transmission, establishing 
a second transmission path, while forwarding the data 
packet sequence, such that the remaining data packets 
of the sequence not yet transmitted over the first path 

50 are forwarded via a second network element, forwarding 
of the data packets buffered In the first network element 
to the second network element for providing all data 
packets comprised by the data packet sequence to the 
user equipment, receiving and ordering of the data 

55 packets within said second network element according 
to the packet data priority given by the data packet se- 
quence, forwarding the ordered data packets to the user 
equipment. 
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[0013] Highly advantageous, the inventive method, 
particularly in case of handover, allows a significant en- 
hancement of the packet data performance by mitigat- 
ing the impact of TCP congestion control effects, which 
would normally occur due to loss of packet order during 
hand off between different network elements. Because 
the inventive method solves the problem of packet re- 
ordering on a higher layer, the requirements on loss-less 
SRNS relocation, which works on the RLC layer, can be 
significantly relaxed. 

[0014] According to a further advantageous refine- 
ment of the inventive method, the data packets received 
by the second network element are assigned to sepa- 
rated data queues in the second network element de- 
pending on their priority in the data packet sequence. 
Thus, a preselection of data packets received is 
achieved, on which basis the ordering or reordering 
process can be completed. 

[0015] In this regard, the assignment is established 
and/or the priority is evaluated on the basis of a preset 
data packet identifier. The packet identifier parameter is 
preset to identify data packets of different and destina- 
tion address and port address within the second network 
element. Thus far. the identifier advantageously makes 
use, as appropriate, of both parameters being known of 
the data packets due to the standardized or at least qua- 
si standardized nature of the transmission protocols ap- 
plied in the state of the art communication systems and 
parameters being defined on the basis of the inventive 
method. In a preferred embodiment for example a pri- 
ority Indicator or priority identifier is defined character- 
izing those data packets from those network elements 
and/or received over those paths having higher priority 
to be sent to a mobile station or user equipment than 
others. 

[0016] The latter identifier parameter, particularly can 
be used in an additional further development of the in- 
vention, wherein the data packets received by the sec- 
ond network element over the second path or over a 
third path via the first network element or over other 
paths via other network elements are buffered in sepa- 
rated data queues depending on which path and/or from 
which network elements the data packets are forwarded 
to the second network element. 
[001 7] Advantageously, for forwarding the data pack- 
ets of each data queue, the data packets received by 
each data queue are worked through in a first-ln. first- 
out manner, and the data queues themselves are 
worked through in an order depending on the priority of 
the data packets, which for instance can be determined 
on the basis of the prionty indicator mentioned above, 
with regard to the data packet sequence comprised by 
the respective data queue. 

[0018] According to a further embodiment of the in- 
vention the ordering step comprises the sub-step as- 
signing a received data packet to a data queue on the 
basis of corresponding data packet identifier informa- 
tion, and sequential ordering of the received data pack- 



ets by applying data packet identifier information. 
[0019] With regard to the foregoing aspect of the in- 
vention, the assignment of the received data packets is 
perfonned by generating and/or identifying a data queue 
5 on the basis of the source address, the destination ad- 
dress and the port address of the received data packet 
being encompassed by the inventive identifier, and 
wherein the sequential ordering is carried out on the ba- 
sis of priority sequence number. 

10 

BRIEF DESCRIPTION OF THE DRAWING. 

[0020] The invention together with additional features 
and advantageous thereof will be best understood from 
15 the following description. 
[0021] It is shown: 

Fig. 1 a diagrammatic view of a UMTS terrestrial net- 
work in case of inter-RNS/intra-SGSN hand- 
20 over. 

Fig. 2 an UMTS, SRNS relocation scenario. 

Fig. 3 a flow chart of a ordering functionality accord- 
ing to a preferred embodiment of the invention. 

25 DETAILED DESCRIPTION OF THE INVENTION. 

First Preferred Embodiment. 

[0022] Starting from the situation described in con- 
30 nection with Fig 1 at the beginning, the basic principle 
of the first embodiment of the invention relies on a gen- 
eration of at least two pnority queues being built per mo- 
bile station (MS) (Fig. 1 ) at the new destination network 
element (RNS#2). the mobile station will be connected 
35 to. Of course, it will be obvious for any person skilled in 
the art that the RNS#2 can be replaced by a radio net- 
work controller (RNC) or an equivalent network element. 
Moreover, at this point it should be noted that by the term 
"packet forwarding" in the context of the invention it is 
40 meant that when centralized mobility related rerouting 
action is performed, the previous destination network el- 
ement forwards the packets to the new destination net- 
work element. 

[0023] The first packets, which have not been sent to 
45 the mobile station so far due to hand-over, come from 
the old network element (RNS#1 ). To preserve the pack- 
et order, those first packets shall be prioritized. When 
no more packets are received from the old network 
(RNS#1) element, then itshall be continued with serving 
50 the second level priority queue, which holds for instance 
the internet protocol (IP) packets forwarded from the 
network element next higher in the routing hierarchy 
(SGSN or equivalent). This network element has al- 
ready started rerouting of the new packets towards the 
55 new lower level network element. 

[0024] Further more, especially with regard to the first 
embodiment of the invention, some further assumptions 
have to be made. First of all it is assumed that the used 
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TCP (transmission control protocol) Is able to accept 
one single reordering without problem. This applies to 
the majority of TCP implementations cun'ently de- 
ployed. Furthermore, the forwarding paths in the terres- 
trial Network are fast. I.e. forwarding from both buffers 
of at least the first IP packet is faster than the transmis- 
sion of any IP packet over a new radio link. Finally, it is 
assumed that the higher level network element forwards 
all stored and newly incoming packets in a FIFO (first 
in, first out) manner to the new lower level network ele- 
ment, i.e. firstly stored packets, secondly new arriving 
packets. 

[0025] Figure 2 depicts a typical networking scenario 
for an intra-servlce GPRS supporting node (intra-SG- 
SN) and an inter-radio network controller (inter-RNC), 
respectively, handoff. I.e. a serving radio subsystem 
(SRNS) relocation. The same scenario is applicable for 
Inter-SGSN handoffs in the same system from a GGSN 
perspective or inter-system handoff, e.g. between 
UMTS and GPRS. Figure 2 describes two paths, where 
(a) was the old path to the previous radio network con- 
troller (RNC.OLD). All packets associated to the same 
mobile station (MS) are previously buffered in queue itO. 
When hand-over occurs, the central routing device (SG- 
SN) from now on fonvards the packets for the mobile 
station that is in hand-off via path (c) to the new desti- 
nation radio network controller (RNC_NEW). At about 
the same time the old destination RNC.OLD forwards 
the remaining, packets that have not yet been sent out 
to the mobile station (MS), from its local queue to the 
new RNC.NEW via path (b). Arrived packets for the 
same mobile station at the new destination RNC_NEW 
can be distinguished based on their source and identi- 
fied to path (b) and path (c) respectively. 
[0028] The inventive method utilizes the path informa- 
tion to queue the packets in RNC^NEW separately. 
Queue #1 contains all packets arriving from path (b) that 
carries the previously buffered data of the old queue #0 
from RNC_OLD marked by (1). Queue #2 contains the 
packets received from path (c) that carries the newly 
packets from SGSN marked by (2). 
[0027] Both queues work in a first in. first out (FIFO) 
manner, i.e. the firstly received packets will be also sent 
first. Therefore, no further treatment of the packets and 
partlculariy no active reordering procedures is neces- 
sary in these queues. The service discipline in the new 
destination RNC_NEW for multiplexing these two 
queues is strictly priority based scheduling: Whenever 
the mobile station gets serviced, queue #1 gets priority 
resulting in queue access (3). over queue #2. Access 
(4) to queue #2 only occurs when queue #1 is empty 
[0028] Thus, the allocation of the received data pack- 
ets into queue #1 or queue #2 can be done by the fol- 
lowing two ways: 

a) The packets are directly identified by detection 
of the source from which they has been routed to 
RNC^NEW. The packets from RNC_OLD associat- 



ed to path (b) are put into queue #1 . The packets 
fmm SGSN associated to path (c) are put into 
queue #2. 

b) The packets are identified by utilizing a priority 
5 indicator that is set in RNC_OLD. The packets from 

path (c) with higher priority indicated are put into 
queue #1 . The packets from path (c) with lower pri- 
ority indicated are put into queue #2. 

10 [0029] This strategy heuristically ensures the priority 
of data path (a) and (b) over data path (c) reducing, the 
negative impact on TCP performance due to IP reorder- 
ing 

[0030] The basic principle described above can be 
15 enhanced to more than two queues. For example, for 
inter-SGSN/inter-RNC hand-off it might be sensible to 
use three different queues, because there are now three 
separate networi< elements involved. In this scenario the 
allocation of the queues In the new RNC could be as 
20 follows: 

a) Queue #1 contains the packets, which have been 
received from the old RNC. They get the highest 
priority. 

25 b) Queue #2 contains the packets, which have been 
received from the old SGSN. They get the second 
highest priority. 

c) Queue #3 contains the packets, which have been 
received from the new SGSN. They get the lowest 

30 priority. 

Second preferred embodiment. 

[0031] In the flow chart according to Fig. 3 an exem- 

35 piary reordering algorithm following preferred embodi- 
ment #2 is depicted. By example, the inventive method 
is also described on an internet based data transmis- 
sion. So far, a direct mapping between the received 
transmission control protocol (TCP) packet and the as- 

40 sociated internet protocol (IP) packet is assumed, i.e. 
no further segmentation has been performed, and if so 
the IP packets are assumed firstly reassembled at some 
instance within the core network, before entering the 
mobility supporting routing system and then they are 

45 processed as described hereinafter. It shall be noted this 
requires the identification of TCP-entities, which is pos- 
sible due to the de-facto standardized nature of the TCP 
format. Based on this, the TCP sequence field can be 
accessed by the inventive method or algorithm. 

50 [0032] The algorithm is performed in the new RNC for 
every received TCP packet irrespective if it is from the 
old RNC or the new RNC. The single steps in detail are 
as follows: 

55 101. The IP insert procedure is started on the re- 
ception of a TCP packet from the old RNC or from 
the SGSN. 

102. Initialize counter i to search all queues asso- 
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dated with the MS. A separate queue for each TCP 

data flow is assumed. 

103. Identify the right queue Q{i), based on source 
IP address IPs, destination IP address IPd and port 
identification number Port, which gets stored as a 5 
triple together with each queue. 

If the queue Q(i) is associated to the incoming TCP 
packet, then the queue exists. Proceed with step 
107. If the queue Q(i) is not associated to the in- 
coming TCP packet, then proceed with step io 

104. Increment counter I. 

105. Check whether a new queue must be created 
by comparing counter i with the total queue counter 
N . If i <= N, then search the next existing queue. Go 
back to step 103. If i > N, then create a new queue. i5 
Proceed with step 106. 

106. Create a new queue Q(i). Store the triple Q(i). 
(IPs, IPd, Port) from the incoming TCP packet for 
identification and increment the total queue counter 

N. Proceed with step 107. 20 

107. initialize the position counter pos. Take queue 
Q = Q{i). 

108. Check if the incoming TCP packet already ex- 
ists at position pos by comparing the queued TCP 
sequence number of the currently handled buffered 25 
TCP packet at position pos Q[pos] with the TCP se- 
quence number of the arrived TCP packet. If the se- 
quence number at pos is equal to the sequence 
number of the arrived TCP packet, then replace the 
buffered TCP packet with the newer one. Go to step ^0 
111. if the sequence number at pos is unequal to 

the sequence number of the arrived TCP packet, 
then the packet does not exist. Proceed with step 
109. 

109. Increment the position counter pos. 35 

110. Check if end of queue is reached, I.e. if Q[pos] 
is undefined. If Q[pos] is undefined, then add it to 
the end. Proceed with step 111 . If Q[pos] is defined, 
then go to step 112. 

111 . Insert the incoming TCP packet at pos. Go to 40 
step 114 (finish). 

112. Cheek whether the arrived TCP packet must 
be inserted before pos in the queue Q by comparing 
the queued TCP sequence number of the currently 
handled buffered TCP packet at position pos Q[pos] ^5 
with the TCP sequence number of the arrived TCP 
packet. If the sequence number at pos is smaller 
than the sequence number of the arrived TCP pack- 
et, then continue the search. Go back to step 108. 

If the sequence number at pos is equal or higher 50 
than the sequence number of the arrived TCP pack- 
et, then insert the TCP packet before pos. 

113. Insert the incoming TCP packet before pos. Go 
to step 114 (finish). 

114. The IP insert algorithm is finished for the mo- 55 
ment. It will be wait until the next TCP packet ar- 
rives. 



Legend for fig. 3: 
[0033] 

Q a packet data queue, FIFO served, 

where 

Q(i) denotes a queue with index i. and 1<= i 

<= N, where 

N is the total number of queues maintained 

per MS (total queue counter). It is equal 
to the number of simultaneously estab- 
lished TCP data flows. Every queue is la- 
beled by a triple 
Q(i) . (IPs, IPd. Port) with 

Ips IP source address. 

IPd IP destination address. 

Port Port number. 

Q(i) [m] denotes the buffered content at Q(i) buff- 
er position m, where m-1 denotes the 
head of the queue and m=<END> the 
last position. 

Q(i)[a...b] denotes a sequence of buffer positions 
in queue Q(i). 

Q{i)[m].seq retrieves the TCP sequence numberfreld 
stored in each IP packet. 

[0034] It shall be noted that the deletion of queues is 
not separately described here and may e.g. be done 
when a queue becomes empty. 
[0035] The proposed algorithm is activated on occur- 
rence of a Inler-RNC hand-off. It shall be de-activated a 
certain time-period after the activation. The duration of 
this time-period is target of optimization with the follow- 
ing constraints: . 

a) If time-period is too small, then after deactivation 
of the algorithm the packets from the old RNC are 
ignored. This may lead to a loss of those packets. 

b) If time-period is too long the algorithm runs only 
on packets arriving from the SGSN, which does not 
need to be processed by the algorithm. This may 
lead to inefficient processing of the packets. 

[0036] Similar to preferred embodiment #1 the same 
algorithm as described above can be also used in case 
of more than two different TCP packet routes. For ex- 
ample, during inter-SGSN/inter-RNC hand-off, three 
separate network elements are involved. 
[0037] A reordering scheme as described above es- 
pecially in connection with embodiment #2 is very robust 
for timing of packet arrivals at the destination node and 
it is also capable of resolving reordering from several 
distributed routing actions in sequence. Therefore, nei- 
ther the number of forwarding routes nor the precise rea- 
sons for the reordering is important. Particularly the han- 
dling of sequential hand-off procedures for fast moving 
mobiles is easy, because buffered data is aggregated 
into a single queue at each hop and only the content of 
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this single buffer is subject for forwarding. 



Claims 

1 . A data packet ordering method in a mobile commu- 
nication network employing hierarchical routing 
with data packet fonwarding comprising the follow- 
ing steps: 

a) providing at least one data flow comprising 
a predefined sequence of data packets, 

b) forwarding at least one of said data packets 
of the sequence via a first network element 
(RNC_OLD) over a first transmission path to a 
user equipment, whereby a part of the data 
packets are temporarily buffered in the first net- 
work element (RNC^OLD) during transmis- 
sion, 

c) establishing a second transmission path, 
while forwarding the data packet sequence, 
such that the remaining data packets of the se- 
quence not yet transmitted over the first path 
are forwarded via a second network 
(RNC_NEW) element. 

d) forwarding of the data packets buffered in the 
first network element (RNC^OLD) to the sec- 
ond network (RNC^NEW) element for provid- 
ing all data packets comprised by the data 
packet sequence to the user equipment, 

e) receiving and ordering of the data packets 
within said second network element 
(RNC_NEW) according to the packet data pri- 
ority given by the data packet sequence, 

f) fonvarding the ordered data packets to the 
user equipment (UE). 

2. The method according to claim 1 , wherein in the or- 
dering step, the data packets received by the sec- 
ond network element are assigned to separated da- 
ta queues in the second network element depend- 
ing on their priority in the data packet sequence. 

3. The method according to claim 2, wherein the as- 
signment is established and/or the priority is evalu- 
ated on the basis of a preset data packet identifier. 

4. The method according to claim 3 wherein the data 
packet identifier is preset to identify the data pack- 
ets of different origin and/or fonwarding path and/or 
destination address and/or port address and/or pri- 
ority sequence number within the second network 
element 



er network elements are buffered in separated data 
queues depending on which path and/or from which 
network elements the data packets are forwarded 
to the second network element. 

5 

6. The method according to claim 5, wherein, for for- 
warding the data packets of each data queue, the 
data packets received by each data queue are 
worked through in a first-in, first-out manner, and 
10 the data queues themselves are worked through in 
an order depending on the priority of the data pack- 
ets with regard to the data packet sequence com- 
prised by the respective data queue. 

^5 7. The method according to claims 1 to 4, wherein the 
ordering step comprises the following sub-steps: 

(i) assigning a received data packet to a data 
queue on the basis of corresponding data pack- 

20 et identifier information. 

(ii) sequential ordering of the received data 
packets by applying data packet identifier infor- 
mation. 

25 8. The method according to claim 7, wherein the as- 
signment is performed by generating and/or identi- 
fying a data queue on the basis of the source ad- 
dress, the destination address and the port address 
of the received data packet and wherein the se- 

30 quential ordering is carried out on the basis of pri- 
ority sequence number. 

9. An apparatus and/or a mobile communication sys- 
tem comprising means for carrying out the method 

35 according to one of the preceding claims. 

10. Computer program having program code means to 
carry out the steps acconjing to one of the claims 1 
to 8, when the program is run in a communication 

40 system and/or on a computer. 



45 



50 



5. The method according to claims 1 to 4, wherein the 
data packets received by the second network ele- 
ment over the second path or over a third path via 
the first network element or over other paths via oth- 
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Fig. 3 



Start IP 
insert 



i = 1 



101 



102 



YES: 
"queue 
exists" 



YES: 
"search next 
queue 

NO: "create 
TCP queue 



106- 



new(Q(i)); 
Q(i).IPs,IPd,Port) = 
IP(IPs,IPd,Port); 
N-N+1 
1 



pos = 1; 
Q = Q(i) 




^107 

YES: "TCP 
packet found, 
replace with 
newer one" 



YES: 
"continue 
search" 



pos =pos + 1 



110 



'109 



YES: "TCP 
pat^etnot 
_ found, add to 
Q[pos]^<^ e/it/" 
unctefined 
?^ 
NO 



112 



111 



Q[pos] = IP 



Q[posJ.seq - 
IPseq 



113- 



NO: "insert 
before pos" 



Q[pos+1 ... <END>*1J = Qfpos ... <END>J; 

Q[posJ-IP; 



114- 



Finish IP 
insert 



9 



EP001383292 fhttp://wvftW - qetthepatent.cx)m/Loqin.doq/$sme/Fetch/EP001383292.^ 

EP 1 383 292 A1 



Page luoi n 



J) 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 02 25 4975 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate. 
ol reievant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (lnt.Cl.7) 



WO 98 47302 A (NOKIA TELECOMMUNICATIONS OY 

;RAUHALA KRISTIAN (US)) 

22 October 1998 (1998-10-22) 

* page 7, line 4 - line 34 * 

* figure 1 * 



DONGWOOK LEE ET AL: "OUT-OF-SEQUENCE 
PACKET ANALYSIS IN MOBILE IP HANDOFF AND 
ITS ENHANCEMENT" 

PROCEEDINGS OF THE 3GWIRELESS 2002, 
[Online] May 2002 (2002-05), XPO02225432 
Retrieved from the Internet: 
<URL : h t tp : // netmedi a . k j i s t . ac . k r/ j ongwon/p 
apers/20023gwi rel ess-mobi 1 ei p .pdf > 
[retrieved on 2002-12-16] 

* the whole documervt * 

.AYANOGLU E ET AL: "AIRMAIlV A iLINK-LAYER 

^PROTOCOL FOR WIRELESS NETWORKS" 

:WIRELESS NETV/ORKS, ACM, US. . 

^vol , 1, no. 1;- .> ; -i 

^1 February 1995 (1995-02-01)-, pages 47-59, 

^XP0OG5O3720 i ' 

:ISSN: 1O22-0D3!8 - ■■ 

* page 53, lefit-haad ccr.l umny- paragraph 5 - 
iright-hand column, '.jparS^raph: 6:.{i*,. 

.* page 57, right-hand cplumn, paragraph 2 
- page 58,. right-hand cplumn, paragraph 3 
* 

* figures 4,12; * 

EP 1 085 779 A (CIT ALCATEL) 
21 March 2001 (2001-03-21) 

* paragraph [d0O4] * 

* paragraph [0019] - paragraph [0020] * 

* paragraph [00731 * 

* paragraph [D108J - paragraph [0113] * 



The present search report has been drawn up for all claims 



1.9.10 



2.5.7 
1.9.10 



H04L29/06 
H04L12/56 
H04Q7/22 



1.9,10 



-. TECHNICAL FIELDS 
SEARCHED (lnt.CI.7) 



K04Q 



1.9,10 



BERLIN 



Date of comploiion of ihe search 

17 December 2002 



Enamlner 

Eraso Helguera, J 



CATEGORY OF CITED DOCUMENTS 

X : particularty relevant if taken alone 

Y : particularly reievant IF combined with another 

document of the same category 
A : techndogical background 
O : non-wrttten disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on. or 

after the filing date 
D : document ched In the application 
L : document cited for other reasons 



& : member of the same patent family, corresponding 
document 



10 



FP001383292 thttp:/^ww■qetthepatent■com/Login■doq/$sfife/Fetch/EP001383292■q)C?fromCache=1part=maintoolbaf=bottom^ 



Page n ot n 



EP1 383 292A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 02 25 4975 



This annex lists the patent family members relating to the patent documents cHed in the above-mentioned European search report. 
The members are as coniairwd in the European Patent Office EDP file on 

The European Patent Office is in no way liable for these particulars which are merely given for the purpose of information. 

17-12-2G02 



. Patent document 


Publication 


Patent family 


Publication 


cited in search report 


dale 


member(s) 


date 



wo 9847302 



22-10-1998 



FI 
AU 
CN 
EP 

WO 

JP 

ZA 



971585 
6835698 
1252918 
0976269 A2 
9847302 A2 
2002501695 
9803090 



A 
A 
T 



T 
A 



16-10-1998 
11-11-1998 
10-05-2000 
02-02-2000 
22-10-1998 
15-01-2002 
20-10-1998 



EP 1085779 



21-03-2001 



FR 
AU 
CN 
EP 
OP 



279881G Al 
5938906 A 
1289215 A 
1085779 Al 
2001148879 A 



23-03-2001 
22-03-2001 

28- 03-2001 
21-03-2001 

29- 05-2001 



u For more details about this annex : see Official Journal of the European Patent Office, No. 12/82 



11 



